前言

在 Day08 介紹過好幾種不同的部署策略，幫助我們完成應用程式的版本更新。本篇要介紹的金絲雀部署是現今常使用的部署策略，至於它的原理是什麼，以及要如何使用 Istio 來實現，就讓我們看下去吧！

什麼是金絲雀部署 (Canary Deployment)

部署策略怎麼會跟金絲雀有關係呢？此名稱的緣由與早期礦坑作業有關，科學家發現小型恆溫動物受到毒氣影響的時間會比人類快，於是發明了讓金絲雀探測毒氣的籠子，在進入礦坑前，礦工能先使用金絲雀測試是否有毒氣。

而金絲雀部署(Canary Deployment) 與拿金絲雀來預警的原理相似，Canary 會先將少部份的流量導入新版本，讓少數使用者測試，若系統運作正常，在逐步將正式環境的流量從舊版本慢慢轉移到新版本。使用 Canary 的優點除了能達成 Zero Downtime (零停機) 之外，若新版本有問題也只會影響少數使用者，從而降低新版本發佈的風險。

使用 Istio 實現 Canary

那要如何在 Istio 實現 Canary 呢？可以使用 Virtual Service 的 Weight Routing 功能實現，Weight Routing 能夠設置不同版本間的流量比例，我們先將小部分流量轉移到新版本，測試沒問題後，在逐步增加流量，直到所有流量都轉移到新版本，就完成了 Canary 部署。

使用 Istio 控制不同版本的流量，逐步將流量從舊版本轉移至新版本

接著就來實驗看看吧！請先參考 Day10 - 準備 Istio 實驗環境 的教學，將 Istio 及 Bookinfo Application 環境準備好，接著就可以依照以下步驟實現 Canary。

1. 先將舊的 destinationRule 與 virtualService 清除

kubectl delete --all destinationRule
kubectl delete --all virtualService

將 Reviews 不同版本的 Pod 用 Destination Rule 進行分組。

2. 建立 destination-rule.yaml 檔案

• destination-rule.yaml

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

3. 使用 kubectl 部署 DestinationRule

kubectl apply -f destination-rule.yaml
kubectl get destinationRule

(輸出結果)

NAME      HOST      AGE
reviews   reviews   49s

再來就可以使用 Virtual Service 定義 Weight Routing ，一開始先將所有流量導入 V1

4. 建立 virtual-service.yaml 檔案

• virtual-service.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 100
    - destination:
        host: reviews
        subset: v2
      weight: 0

5. 使用 kubectl 部署 VirtualService

kubectl apply -f virtual-service.yaml
kubectl get virtualService

(輸出結果)

NAME      GATEWAYS   HOSTS         AGE
reviews              ["reviews"]   9s

6. 使用 kubectl port-forward 將流量轉入應用程式

kubectl port-forward svc/productpage 8080:9080

這是可以開啟瀏覽器查看，或是使用 Curl 指令來檢查版本

目前流量皆為 v1 版本

7. 接著修改 virtual-service.yaml 檔案，修改 weight 比例為 75:25

• virtual-service.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 75 # change to 75
    - destination:
        host: reviews
        subset: v2
      weight: 25 # change to 25

8. 使用 kubectl 部署 VirtualService 後，在進入網站檢查版本變化

kubectl apply -f virtual-service.yaml

會發現有些流量轉入 v2 版本，但大部分都是 v1 版本

9. 重複修改 weight 流量比例並檢查版本變化，直到 v2 版本的流量變為 100%

v1 版本與 v2 版本 Weight 各為 50% 的情形

流量全部轉移至新版本，代表完成 Canary Deployment 整個流程，可以再嘗試從 v2 更新至 v3 看看

總結

本章使用 Istio 的 virtualService 輕鬆完成 Canary Deployment ，是不是開始感受到 Istio 的威力，下一章我們會介紹另一個部署策略 A/B Testing ，讓你更了解 Istio 的使用方式。